Cross-site scripting (XSS) is a widespread web-based attack technique and has been a leading web attach vector for some time. A web site with XSS vulnerability can be exploited by a malicious attacker to launch serious attacks against it, a company's computer network, as well as its customers. This can lead to loss of confidential information, identity theft, and/or installation of viruses and Trojans, even reaching behind corporate firewalls.
XSS attacks stem from a web design feature: there is no clear demarcation separating JavaScript programs from other web data such as Hypertext Markup Language (HTML) and Cascading Style Sheets (CSS) data streams. A typical web page uses format definition languages (e.g. HTML, CSS) to specify page layout (e.g. tables, placement of pictures), as well a programming language to define certain behavior of the web page (e.g. what happens when a mouse is clicked). JavaScript programs can be intermixed with other web data in very complicated ways, affording malicious JavaScript programs to be injected into a legitimate web data stream and cause malicious logic to be executed on a client device. An XSS attack exploits design flaws in the web page by injecting a malicious JavaScript program to the vulnerable web page, thereby making the web page exhibit malicious behavior. Unfortunately, there is no easy way to prevent all XSS attacks. The best practice is to encourage developers to sanitize untrusted data before placing them into the web stream. However, there is no one-size-fit-all solution to perform whitelist-based data sanitization for web data streams that can prevent XSS attacks while preserving legitimate web functions.
State of the Art XSS prevention falls into two categories: 1) defensive web programming, and 2) using Content Security Policy (CSP) compatible browsers. Defensive web programming (as exemplified by the programming guidelines offered by the Open Web Application Project, www.owasp.org) focuses on educating web site developers to properly sanitize untrusted dynamic web content to prevent XSS. Because many web sites are very complex, mistakes are difficult to avoid entirely, as evidenced by the large number of XSS vulnerabilities reported (e.g. www.xssed.com).
Content Security Policy (CSP) is a proposal to combat XSS is part of the Content Security Policy (CSP) introduced by the Mozilla Foundation in Firefox 4 and adopted as a W3C candidate in 2012. It mitigates XSS attacks by prohibiting in-line JavaScript execution in the browser. All major browsers are supporting it today. XSS protection is one of the major goals of CSP. It can be summarized by the following four components: (1) New versions of CSP-compliant browsers must be used; (2) CSP assumes legitimate JavaScript programs can be enumerated before run time; (3) Dynamic evaluation of JavaScript programs using the “eval” function is not permitted; and (4) No inline JavaScript programs are permitted. All legitimate JavaScript programs must be contained in dedicated files. The website will instruct a CSP-compliant browser to load approved JavaScript files from approved web locations. By banning inline JavaScript programs, CSP achieves a clear separation of JavaScript programs from other web data stream. The requirement that all in-line JavaScript code must be “pulled out” and placed in trusted directories poses a significant challenge to most web sites as JavaScript are often interlaced with web content and format specifications. This effort, particularly the effort required to test the restructured web site, is often prohibitively expensive in practice. Because most web sites are incrementally built upon existing code, it is very difficult to take advantage of the benefit of CSP. The adoption rate for CSP has therefore been extremely low.
There is therefore a need in the field for new computer implemented methods and systems to prevent cross-site scripting vulnerabilities.